Talk:Modding
'%s weirdness' It is important to note that while this can be used with crafting recipes, it displays certain weirdnesses. Using wood objects results in 'Tunematon ' and using stone or rock results in 'club There's some interesting weirdnesses here. KuuOtava (talk) 04:29, September 21, 2014 (UTC) '{TERRAIN:} Weirdnesses' It has been revealed that the {TERRAIN:} parameter will occasionally seem to function with invalid terrain types. What is actually going on here is that those terrains return a 0 value in the parameter. When the code goes to find the type of terrain you're in in the game, it also returns a zero value, making it seem to function in a recipe. This is something of a work-around for things like caves, but comes with it's own issues, since it's essentially an exploit or bug. {TERRAIN:cave} will appear to work in caves, but if you add a valid terrain type {mountain} It will continue to work with mountains, but will no longer be valid for caves. This is as per Sami KuuOtava (talk) 05:41, September 21, 2014 (UTC) Patch: This parameter is almost always seen in connection with patchwise, which indicates (when put behind a resource that is removed in the recipe) that the amount of resources removed corresponds with the patch-size. (put an example here)'' ''Skill-modifier: %xx% It doesn't precisely work like a raw addit''ion/substraction of the base-skill. The result of a recipe if more determined like this: The base-skill-value + raw-material + tool-value that don't have a noquality tag behind it will determine the range of outcomes, so with a medium base-skill + tools you could at max build a fine item, etc. There is a chance of scoring high or low in this range which is modified by the %xx% skill-modifier. THis is not exactly intuitive, considering the name 'skill-modifier', also '''the notion concerning this in news.txt '''can be a bit misleading, but how I understand it, and also have gathered from 1000s of tests is that this is the way it more or less works. There are other factors involved in the final result which are quite obscure and probably are also meant to be this way. '''Wildcard' Note that when there's a space between the asterisk and the rest of the words that space is mandatory in the item-name. {* fur hood} will not accept a regular 'fur hood' {*fur hood} will. preferred item There is a quality penalty-modifier when using the preferred item or not implemented for some tools axes and some knives, but not all, and it certainly doesn't apply to custom named items. A wildcard-trick like this {*Hunting knife} Will not favor a stained hunting knife above any other that fits the description. '#weight#' Note that although probably you can specify a weight for all ingredients used, only some of them will actually subtract the weight from the used item, when you drop the item and pick it up again in some cases the object will be restored to it's full weight. Resources that can always be partly used are in any case: foods (beverages), hides (cloth etc.), all kinds of timber, ... ? 'Building specific parameters' Buildings should all be put in biy_customname.txt Recipes should always use the *BUILDING* skill or they won't be recognized. A big difference in the way the recipe is set up is that first you state the object that will be build, there are no custom objects possible yet, and then you state the description in the menu, like so: .Road. "Dig a road" *BUILDING* In contrast with regular recipes where it would be the other way around .Dig a road. "Stone" *COMMON* In both cases the menu-item will be called 'dig a road'. Note that you can build just about every tile you see in the zoomed-in as well as in the zoomed-out map. SO that includes a mountain, camp, settlement, or zoomed in: sea, field, pasture, high cliff, big rock, etc. Creating a new recipe for a pre-existing item a bench would conflict with the original one, so it's not possible the have recipes for both indoors and outdoors benches for instance. Creating a recipe for any object to be buildable will always result in that object also being deconstructable from the building-menu. Because you cannot access this menu on the zoomed-out map, constructed tiles that only exist there are safe. '%s' Behind the name tag you have two optional additional tags, naming:original and last word Behaviour not entirely clear.. '{NEARBY_TILE}' You also have a TILE: tag that obligates you to be on the actual tile specified. '+'descriptive text It doesn't work like this exactly, if you add a + the original item between {brackets} will also show in the description. If you omit the +, only the text between 'accolades' will be shown. {Knife} '+for hunting' = Knife for hunting' {Knfie} 'for hunting' = 'for hunting' 'Ground' This tag does not always work, certainly not for items that are specified with the usage of a wildcard. 'Noquality' Tag can be put in the header of the recipe, which will make the entire result decent always, or put behind any of the required ingredient, which will ignore this objects quality. Note that some objects that are always neutral qualitywise, like branches, rocks and so on, can have a averaging effect that proper english? on the result, putting noquality behind those items make the recipe more dependent on the other factors. '''Item list' This is not actually an item-list would be much longer and includes all the items in the game, and some other that used to be in there, like a necklace, anklet, but a category-list. Animal hide is a category for all kinds of fur. Tying equipment is a category for both ropes and the cord. Grinding stone doesn't seem to work 3.19 11:53, September 23, 2014 (UTC)Simon skil-advance Note that skill advances are also determined by the amount of succes that has been achieved while creating the recipe, this make recipes with a positive modifier %xx% more likely to result in skill-advances. by Sami Simon 12:40, September 23, 2014 (UTC)